Existing email systems may be centrally controlled. Simple Mail Transport Protocol (“SMTP”) is the de facto standard used on the internet today. A first SMTP server (e.g., mail.yin.com) may receive email messages from SMTP clients (e.g., Microsoft® Outlook, Mozilla® Thunderbird) executing on computers in the first SMTP server's domain. The email messages may include one or more recipient email addresses (e.g., john@yang.net). The first SMTP server may route the received messages to a second SMTP server on the intended recipient's domain (e.g., mail.yang.net) using known systems such as the domain name system (“DNS”). After receiving the email message, the second SMTP server may deliver the email messages to the intended recipient's mailbox, which may be stored on the second SMTP server and made available to the intended recipient over the network.
SMTP servers may be configured to restrict the size of attachments which may be sent with an email message. Other SMTP servers may limit the amount of storage space (i.e., the size of a mailbox) allocated to a user to store emails and attachments. Still other SMTP servers may not protect or offer the capability of protecting emails and attachments associated therewith from malicious or otherwise unintended recipients, either locally or while in transit over a computer network.
In addition to the above, unsolicited advertising emails (“SPAM”) are ubiquitous on the Internet. It is estimated by some that as of 2007, 90 billion SPAM messages are sent every day, and that so-called “abusive email” accounts for up to 85% of incoming mail in a given email inbox.
Moreover, existing email systems exhibit various inefficiencies. For instance, centralized email server farms are estimated to consume over two billion dollars worth of energy annually around the world. In addition, current methods of encoding attachments involve the use of base64, which encodes attachments as 7-bit representations, rather than traditional 8-bit. Base64 introduces approximately 30% of overhead to each attachment sent. Some estimate that attachments make up 80% of email traffic on the Internet. CPU cycles are also required to perform this encoding on the sending user's computer, as well as perform the decoding on the recipient user's computer. This processing inefficiency for changing encoding of attachments from 8-bit to 7-bit and back to 8-bit is a material significant overhead for large files such as HD videos.
Email users often desire to exchange video files, but video files, including high resolution video files suitable for large screens and HD displays such as HD video, blu-ray video, Imax, and 3D video files, typically are quite large, and as noted above, many email systems will not permit the exchange of attachments beyond a certain size. A meter or other indicator of the progress of sending and delivery in the email user interface is a feature of the client interface of the invention. This feature allows the user to see the progress of sending and receiving large file so that they do not become confused as to the status of the delivery. Playing the incoming file, such as an HD video file, as it is being delivered is also desirable, and the invention permits that to occur, so that when a large video file is sent, the user can play it during the process of arriving, and play it to conclusion while the rest of it is delivered, all in high resolution on a large format display such as an HD television or display. Using those types of displays will also afford the use of video advertisements including large-file, high-resolution video advertising whether delivered or streamed, paid delivery services, and other revenue-generating aspects into video file exchange.